I think this change as it is, is a bit incomplete. If an app/client is supposed to call this API, it needs to be added to the org.freedesktop.portal.OpenURI instead, because your addition is what backend implementations (xdp-kde/xdp-gnome) are supposed to implement, but these APIs are not called directly by clients and possibly not even visible outside the sandbox by default. With an additional API, you should also bump a version of the org.freedesktop.portal.OpenURI so clients can check whether the version of xdp that is running on the host supports it. I'm not sure a backend counterpart is needed as you can probably tell the host can handle given scheme using the g_app_* APIs (I'm not an expert in this regard). That would mean that also the implementation of this additional API is missing in this MR.

@xhorak also please squash your commits or split it to reasonable parts and remove the merge commit.

@matthiasclasen Could you please check this one?

This needs a rebase.

Also, see #1375. You will have to bump version to 5. Also at the top of the XML file there is a sentence This document describes interface in version 4 which needs to be updated too.

I also wonder whether this shouldn't be more generic, e.g. looking at #1313, this will make OpenURI to handle more than schemes. Maybe something like having URISupported which is probably a terrible name, but just to give you the sense what I mean.

Also, OpenURI gives you an option to install an app that can possible handle the requested scheme if there is none on the system. With your SchemeSupported call, you will end up making Firefox to handle it itself, because you don't get to call the OpenURI. Just mentioning this as something to think about as I don't have a solution to this.

Also, maybe this can be permission based? To address @matthiasclasen concerns?

Like, first ask will popup a permission dialog, to ask whether you want to allow given application access to this information, store it for this app (app_id) and have all the following ones without any permission dialog needed in case the permission has been granted already?

That would mean using the generic Access portal for this.

@matthiasclasen we need to move forward with this. Please set some reviewer or check the PR on your own.

Seems perfectly reasonable. What are the concerns about exposing this by default (i.e. not gated behind some permission)?

The xml still has to be adjusted and a test would be nice, as pointed out by @grulja.

I think the test is failing because you need to also bump the version in the test file. Still better would be to not just bump it, but also wrote a simple test.

Seems perfectly reasonable. What are the concerns about exposing this by default (i.e. not gated behind some permission)?

The xml still has to be adjusted and a test would be nice, as pointed out by @grulja.

Looking at the tests, they seems to be mostly implemented by libportal. Maybe we could add more when the libportal adds SchemeSupported implementation?

Seems perfectly reasonable. What are the concerns about exposing this by default (i.e. not gated behind some permission)?
The xml still has to be adjusted and a test would be nice, as pointed out by @grulja.

Looking at the tests, they seems to be mostly implemented by libportal. Maybe we could add more when the libportal adds SchemeSupported implementation?

You can make a simple sync DBus call there.

In the file org.freedesktop.portal.OpenURI.xml at line 32 it still says version 4.

Otherwise this LGTM!

In the file org.freedesktop.portal.OpenURI.xml at line 32 it still says version 4.

Oh sorry, I've somehow only focused on the line 176.

@swick since 1.19.0 is not out yet, can we get this change in?

can we get this change in?

This merge request was merged 3 weeks ago.

since 1.19.0 is not out yet

1.19.0 is out. This change was merged after that, and will be in the 1.19.1 development release and the 1.20.0 stable release.